Tricks of the Mac Game Programming Gurus/TricksOfTheMacGameProgrammingGurus.iso/Information/CSMP Digest/volume 1/csmp-v1-201.txt

Text File | 1994-12-08 | 42.0 KB | 1,099 lines | [TEXT/R*ch]

C.S.M.P. Digest             Sun, 01 Nov 92       Volume 1 : Issue 201

Today's Topics:

    Color Icon questions in menubar (Was Re: Color Questions)
    Disassembler?
    LED Lights Test [code]
    Help: Resources and 'STR#'
    making Bit maps
    Looking for LDEF



The Comp.Sys.Mac.Programmer Digest is moderated by Michael A. Kelly.

The digest is a collection of article threads from the internet newsgroup
comp.sys.mac.programmer.  It is designed for people who read c.s.m.p. semi-
regularly and want an archive of the discussions.  If you don't know what a
newsgroup is, you probably don't have access to it.  Ask your systems
administrator(s) for details.  (This means you can't post questions to the
digest.)

Each issue of the digest contains one or more sets of articles (called
threads), with each set corresponding to a 'discussion' of a particular
subject.  The articles are not edited; all articles included in this digest
are in their original posted form (as received by our news server at
cs.uoregon.edu).  Article threads are not added to the digest until the last
article added to the thread is at least one month old (this is to ensure that
the thread is dead before adding it to the digest).  Article threads that
consist of only one message are generally not included in the digest.

The entire digest is available for anonymous ftp from ftp.cs.uoregon.edu
[128.223.8.8] in the directory /pub/mac/csmp-digest.  Be sure to read the
file /pub/mac/csmp-digest/README before downloading any files.  The most
recent issues are available from sumex-aim.stanford.edu [36.44.0.6] in the
directory /info-mac/digest/csmp.  If you don't have ftp capability, the sumex
archive has a mail server; send a message with the text '$MACarch help' (no
quotes) to [e-mail] for more information.

The digest is also available via email.  Just send a note saying that you
want to be on the digest mailing list to [e-mail], and you will
automatically receive each new issue as it is created.  Sorry, back issues
are not available through the mailing list.

Send administrative mail to [e-mail].


-------------------------------------------------------

From: [e-mail] (Leonard Rosenthol)
Subject: Color Icon questions in menubar (Was Re: Color Questions)
Date: 23 Sep 92 17:04:22 GMT
Organization: Netcom - Online Communication Services  (408 241-9760 guest)

In article <1992Sep22.215315.21568@sagpd1> bberqu@sagpd1 () writes:
>In article <1992Sep14.225645.3163@sagpd1>, bberqu@sagpd1 () writes:
>>
>> In an application I'm writing I've got a color menu with three different
>> menu items each having a color icon to the left of the menu item (you
>> know just like the Labels menu on the desktop), Now when you select
>> each one of the menu Items it brings up the Color Picker, my problem is
>> how do I make the color Icons in the menu change to the color selected
>> with the color picker?
>>
    The correct way to do this is to write your own MDEF.  That way
you can set up the data and draw ANY WAY you want!! The other (much harder)
way would be to munge color table in the cicn.

- --
- -----------------------------------------------------------------------------
Leonard Rosenthol            Internet:     [e-mail]
Director of Advanced Technology        AppleLink:    MACgician
Aladdin Systems, Inc.            GEnie:        MACgician

+++++++++++++++++++++++++++

From: [e-mail] (Bathsheba Grossman)
Date: 24 Sep 92 04:57:30 GMT
Organization: Extended Bulletin Board Service

>>In article <1992Sep14.225645.3163@sagpd1>, bberqu@sagpd1 () writes:
>>> In an application I'm writing I've got a color menu with three different
>>> menu items each having a color icon to the left of the menu item (you
>>> know just like the Labels menu on the desktop), Now when you select
>>> each one of the menu Items it brings up the Color Picker, my problem is
>>> how do I make the color Icons in the menu change to the color selected
>>> with the color picker?
>>>
>    The correct way to do this is to write your own MDEF.  That way
>you can set up the data and draw ANY WAY you want!! The other (much harder)
>way would be to munge color table in the cicn.

A less drastic possibility might be to fool with the menu color table
using GetMCEntry and SetMCEntries.  This is relatively painless
compared with writing an MDEF, and I successfully used it for this exact
purpose.

- -Sheba

- --
   The opinions expressed are not necessarily those of the University of
     North Carolina at Chapel Hill, the Campus Office for Information
        Technology, or the Experimental Bulletin Board Service.
           internet:  bbs.oit.unc.edu or 152.2.22.80

+++++++++++++++++++++++++++

From: [e-mail] (marco piovanelli)
Date: 24 Sep 92 13:45:45 GMT
Organization: Computer Science Dep. - Milan University

[e-mail] (Leonard Rosenthol) writes:

>In article <1992Sep22.215315.21568@sagpd1> bberqu@sagpd1 () writes:
>>In article <1992Sep14.225645.3163@sagpd1>, bberqu@sagpd1 () writes:
>>>
>>> In an application I'm writing I've got a color menu with three different
>>> menu items each having a color icon to the left of the menu item (you
>>> know just like the Labels menu on the desktop), Now when you select
>>> each one of the menu Items it brings up the Color Picker, my problem is
>>> how do I make the color Icons in the menu change to the color selected
>>> with the color picker?
>>>
>    The correct way to do this is to write your own MDEF.  That way
>you can set up the data and draw ANY WAY you want!! The other (much harder)
>way would be to munge color table in the cicn.

Munging the cicn color table isn't that difficult.
In fact, it seems to me that this is exactly what Finder 7.x does for
its Label menu.  The Finder has 7 identical black cicn resources.
When it loads them into memory, it changes a 6-byte block in one
of the cicn color table entries, and the trick is done!
Of course, the cicn resource has to be made unpurgeable.
I've used this technique for exactly the above described purpose
in a couple of applications and it always worked without a glitch.

In comparison, writing a MDEF (with all the weird things a MDEF must
care about nowadays: Balloon Help, scrolling indicators, real-gray
dimming, Script Mgr support, etc etc) would be a royal pain.

---------------------------

From: [e-mail] (Matt Daw)
Organization: MAGIC - Macintosh Awareness Group In Canada
Date: Fri, 18 Sep 1992 16:33:11 EST
Subject: Disassembler?

Is there such as thing as a disassembler to get source code from
programs? Is it legal?


+++++++++++++++++++++++++++

From: [e-mail] (Tim Endres)
Date: Sat, 19 Sep 92 13:28:03 EST
Organization: ICE Engineering, Inc.


In article <[e-mail]> (comp.sys.mac.programmer), [e-mail] (Matt Daw) writes:
> Is there such as thing as a disassembler to get source code from
> programs?

Yes!

> Is it legal?

NO! (generally speaking)


tim endres - [e-mail]  -or- tbomb!time
ICE Engineering, Inc - 8840 Main St, Whitmore Lake, MI 48189
Phone [phone] - FAX [phone]
USENET - a slow moving self parody... ph

+++++++++++++++++++++++++++

From: [e-mail] (Michael Peirce)
Date: 19 Sep 92 19:25:57 GMT
Organization: Peirce Software


In article <[e-mail]> (comp.sys.mac.programmer), [e-mail] (Matt Daw) writes:
> Is there such as thing as a disassembler to get source code from
> programs? Is it legal?

There is a good one called MacNosy available from Jasik Designs.
It is very smart about how it disassemblers a Mac program and it know
about most types of code segments.

As to the legality, it depends on what you do.  If you disassemble
something so you can copy if verbatum and make a knock off clone you
can expect legal troubles.  If you are just looking out of curiousity
then there is no problem.  And there is a grey area in between :-)

- --  Michael Peirce      --   [e-mail]
- --  Peirce Software     --   Suite 301, 719 Hibiscus Place
- --                      --   San Jose, California USA 95117
- --  Makers of...        --   voice: [phone] fax: [phone]
- --            SMOOTHIE  --   AppleLink: peirce & America Online: AFC Peirce

+++++++++++++++++++++++++++

From: [e-mail] (HP48SX Archive Maintainer)
Date: 19 Sep 1992 16:57:04 -0500
Organization: Washington University in Saint Louis, MO USA

[e-mail] (Matt Daw) writes:

>Is there such as thing as a disassembler to get source code from
>programs? Is it legal?

Yes, there is MacNosy from Jasik which is very good, and then there is
the worse solutions like MacsBug and TMON Pro 3.0, which both are low
level debuggers.

And then finally there is a free solution: ResEdit and the CODE  editor
available from ftp.apple.com. Sometimes I prefer them to TMON, but
serious hacking, and copy protection removal both needs a good
debugger.
- --
Povl H. Pedersen             [e-mail]
HP48sx archive maintainer

All Opinions (C) Copyright the Intergalactic Thought Association

+++++++++++++++++++++++++++

From: [e-mail] (Elliotte Rusty Harold)
Date: 20 Sep 92 13:52:14 GMT
Organization: New Jersey Institute of Technology

In article <[e-mail]>, [e-mail] (Tim Endres) writes:
>
> In article <[e-mail]> (comp.sys.mac.programmer), [e-mail] (Matt Daw) writes:
>> Is there such as thing as a disassembler to get source code from
>> programs?
>
> Yes!
>
>> Is it legal?
>
> NO! (generally speaking)
>

    Actually writing, distributing or owning a disassembler is perfectly
legal.  At least in the U.S. portions of the net, here is this little thing
called the First Amendment, endangered thought it may be.  Use of such an item
may (or may not) be legal depending on exactly what it is you disassemble.  For
instance I've recently taking to writing small programs in C, compiling them,
and then disassembling them to help me with my understanding of 68000 assembly
language and how it compares to VAX assembly.  (Unfortunately VAX assembly is
the only kind NJIT teaches.)  It's at least arguable whether or not it is
legal to disassemble someone else's code that came with a specific license
restricting disassembly.

    Remember, writing or owning a program whose use may
be of questionable legality is not the same as using such a program to actually
violate the law.  Most so-called "black code" has legal as well as illegal
uses.  Programs that break copy-protection can be used to make backups.
Demon Dialers can be used to check a company's internal phone lines.  Password
crackers can be used to test the security of your system.  There's even a
discussion of the possibility of releasing viruses and worms to propagate
certain bug-fixes in system software.

Elliotte Rusty Harold        Department of Mathematics
[e-mail]        New Jersey Institute of Technology
[e-mail]        Newark, NJ 07102

+++++++++++++++++++++++++++

From: [e-mail] (Francois Menneteau)
Date: 23 Sep 92 13:25:57 GMT
Organization: IMAG Institute, University of Grenoble, France

In article <[e-mail]> [e-mail] (Michael Peirce) writes:
>
>In article <[e-mail]> (comp.sys.mac.programmer), [e-mail] (Matt Daw) writes:
>> Is there such as thing as a disassembler to get source code from
>> programs? Is it legal?
>
>There is a good one called MacNosy available from Jasik Designs.
>It is very smart about how it disassemblers a Mac program and it know
>about most types of code segments.
>

There is an application (I developped) called rsc viewer (at sumex in demo
folder) that disassembles application and many kind of resources. there is
also an assembler and many useful features (such as searching for a trap
name for example). It is only shareware.





- --
Francois Menneteau ()   __|||||__   () "... I had their lives in my hands
================== ()    /O   O\    () their fate their fortune in my visions
[e-mail]       ()    - .|. -    () No one believed in my true prophecy
================== ()     \=^=/     () And now it's too late."  (Iron Maiden)

+++++++++++++++++++++++++++

From: [e-mail] (Matt Daw)
Organization: MAGIC - Macintosh Awareness Group In Canada
Date: Thu, 24 Sep 1992 17:06:23 EST

I have a program that will give me assembly back but I was talking about
like C or Pascal source files? If there is such a thing...what I want to
do is to dissasemble some registered shareware and find out how they
work to help me learn....

+++++++++++++++++++++++++++

From: [e-mail]
Date: 27 Sep 92 11:20:19 GMT
Organization: Actrix Information Exchange

In article <[e-mail]> [e-mail] (Matt Daw) writes:
> I have a program that will give me assembly back but I was talking about
> like C or Pascal source files? If there is such a thing...what I want to
> do is to dissasemble some registered shareware and find out how they
> work to help me learn....

Do you want one that will give back the original comments, or will
just the original variable names do?  Does it matter if a Pascal
program gets decompiled as C, or should it be smart enough to
recognise that?  How about C++, FORTRAN and Modula-2?

- --
[e-mail]   Twisted pair: [phone]
BIX: brucehoult                 Last Resort:  PO Box 4145 Wellington, NZ
"Cray's producing a 500 MIPS personal computer with 256MB RAM and 8 GB
hard disk that fits in your pocket!"   "Great!  Is it PC compatible?"

+++++++++++++++++++++++++++

From: [e-mail] (Dana S Emery)
Date: 28 Sep 92 15:25:08 GMT
Organization: Personal

In article <[e-mail]>,
[e-mail] wrote:
>
> In article <[e-mail]> [e-mail] (Matt Daw) writes:
> > I have a program that will give me assembly back but I was talking about
> > like C or Pascal source files? If there is such a thing...what I want to
> > do is to dissasemble some registered shareware and find out how they
> > work to help me learn....
>

[Bruce's sarcastic comments expunged]

Compilation is generally not a reversable process.  Usually, all comments
are discarded, symbolic names are bound to arbitrarily assigned constants,
and ultimatly to machine code.  Frequently, an optimising compiler will
emit code which reflects the order of the original, and will then rearange
that code into something equivalent, but not necessarily evocative of the
original. In the Mac environment, routine names often interleave with
code threads, and are referenced by symbolic debuggers (a practice started
by motorala with its macsbug).

Some compilers leave enough information available for a symbolic debuger to
refer back to the code, but this information is often skimpy.  In many
cases, data and instructions are intermixed to such an extent that it is
difficult to distinguish them.

And all the above asumes that the language gets compiled into native 68000
code.  Some compilers (Basic, Forth, ? Lisp) emit code which is executed by
a run-time state machine.  Digging into that stuff will drive anyone batty.

The derivation of source code from executable object code involves a
process called reverse engineering, and often involves grey arts and
obscure tools.  It is often necessary, but is always nasty.
- --

Dana S Emery <[e-mail]> | "Novo, de Novo,
                                  |     de novo, de no-o-o-o-o---,
                                  | Novemba come an' dey gonna go home."

---------------------------

From: [e-mail] (Hank Woods)
Subject: LED Lights Test [code]
Date: 23 Sep 92 05:28:53 GMT
Organization: FidoNet node 1:125/222.0 - Macademe/Emma, San Francisco CA

A couple weeks ago someone posted in this newsgroup some code that would
make the LED lights on the mac keyboard blink on and off (to show a
client that the lights on the keyboard relly worked) , but I forgot to
capture the text, can the person who posted the code please repost that
code again, so I can study it..Thanks1



- --
Hank Woods - via FidoNet node 1:125/555
    UUCP: ...!uunet!hoptoad!kumr!fidogate!222.0!Hank.Woods
INTERNET: [e-mail]

+++++++++++++++++++++++++++

From: [e-mail] (Kent Sandvik)
Date: 26 Sep 92 01:20:19 GMT
Organization: Apple

In article <[e-mail]>,
[e-mail] (Hank Woods) wrote:
>
> A couple weeks ago someone posted in this newsgroup some code that would
> make the LED lights on the mac keyboard blink on and off (to show a
> client that the lights on the keyboard relly worked) , but I forgot to
> capture the text, can the person who posted the code please repost that
> code again, so I can study it..Thanks1

Didn't Greg Robbins write something similar? Yep, it's placed on the
Developer CD, do a find on 'ledApp'.

Kent/DTS
- -------------------
Kent Sandvik (UUCP: ....!apple!ksand; INTERNET: [e-mail])
DISCLAIMER: Private activities on the Net.

+++++++++++++++++++++++++++

From: [e-mail] (Grobbins)
Date: 26 Sep 92 19:57:56 GMT
Organization: Apple Computer Inc., Cupertino, CA

In article <[e-mail]> [e-mail] (Kent Sandvik) writes:
>In article <[e-mail]>,
>[e-mail] (Hank Woods) wrote:
>> A couple weeks ago someone posted in this newsgroup some code that would
>> make the LED lights on the mac keyboard blink on and off
>Didn't Greg Robbins write something similar? Yep, it's placed on the
>Developer CD, do a find on 'ledApp'.

ledApp should also be in the snippets collection in the dts area of
ftp.apple.com.  Anyway, pasted below is the portion relevant to setting
the LEDs.  Documentation for ADB is in IM V and in the ADB Tech Note
("Space Aliens Ate My Mouse".)

Grobbins               [e-mail]

Usual disclaimers apply.

- ---

from ledApp.p:

  FUNCTION GetA2: LONGINT;
    INLINE $2E8A; { put A2 on stack }

  PROCEDURE CompADBOp;
  { completion routine for ADB talks and listens }
    TYPE
      boolPtr = ^BOOLEAN;
    VAR
      completionFlagPtr: boolPtr;
    BEGIN
      { set flag to indicate completion routine has run; A2 points to the flag }
      completionFlagPtr := boolPtr(GetA2);
      completionFlagPtr^ := TRUE;
    END;

  PROCEDURE DoSetLEDs(ledPat: BYTE);
  { set the leds to the given pattern }
    TYPE
      ADBregBuffType = PACKED ARRAY[0..8] of BYTE;

    VAR
      retCode:  OSErr;
      i: INTEGER;                  { index through ADB devices }
      numADBs: INTEGER;              { total number of ADB devices }
      anADBDB: array[1..16] of ADBDataBlock;    { data block for each device }
      anADBadd: array[1..16] of ADBAddress;    { address of each device }
      regBuff: ADBregBuffType;          { buffer for ADBOp commands }
      oldReg: BYTE;
      completionFlag: BOOLEAN;

    BEGIN
      numADBs := CountADBs;

      FOR i:=1 to numADBs DO
        BEGIN
          { get an address for an ADB device }
          anADBadd[i] := GetIndADB(anADBDB[i], i);

          { a keyboard has an original address of 2, but the actual ADB address
            may change if there is a conflict; a U.S. extended keyboard has a
            device type ("handler ID") of 2, but unfortunately some other ADB
            devices also do }
          IF (anADBDB[i].origADBAddr = 2) AND (anADBDB[i].devType = 2) THEN
             { ext keyboard }
            BEGIN
              regBuff[0] := BYTE(2); { initial data buffer length }

              { talk }
              completionFlag := FALSE;
              retCode := ADBOp(@completionFlag, @CompADBOp, @regBuff,
                 kTalkCommand + kLEDRegister + 16 * anADBadd[i]);

              IF retCode <> noErr THEN
                EXIT(DoSetLEDs);

              { do nothing until completion routine has run }
              REPEAT
                ;
              UNTIL completionFlag;

              { extended keyboard has a word of data, LEDs are low 3 bits }
              oldReg := regBuff[2];

              { set the specified bits; note that a clear bit indicates a
                lit LED }
              regBuff[2] := BOR(BAND(oldReg, 255-7), 7 - LedPat);

              { listen }
              completionFlag := FALSE;
              retCode := ADBOp(@completionFlag, @CompADBOp, @regBuff,

                kListenCommand + kLEDRegister + 16 * anADBadd[i]);

              { do nothing until completion routine has run }
              REPEAT
                ;
              UNTIL (retCode <> noErr) OR (completionFlag);

            END; { if }
        END; { for }
    END; { DoSetLEDs }

---------------------------

From: [e-mail] (Al Hallstrom)
Subject: Help: Resources and 'STR#'
Organization: University of Washington, Seattle
Date: Wed, 23 Sep 1992 22:50:24 GMT

I am writing a program that adds a new 'STR#' resource.  My problem is that
I don't quite understand the format.  I know the number of string is in
the first spot and then all the strings after that.

My Question:  Is there a function that will add these strings to the resource
of do I have to "manually" put them in?

Thanks in advance.

- -Philip
[e-mail]


+++++++++++++++++++++++++++

From: [e-mail] (Pete Resnick)
Date: 24 Sep 92 01:04:51 GMT
Organization: University of Illinois at Urbana

[e-mail] (Al Hallstrom) writes:

>I am writing a program that adds a new 'STR#' resource.  My problem is that
>I don't quite understand the format.  I know the number of string is in
>the first spot and then all the strings after that.

>My Question:  Is there a function that will add these strings to the resource
>of do I have to "manually" put them in?

As far as I know, you have to add them by hand (i.e. figure out what
position to put them in, etc), but Munger is a nice routine to do this
with. Check it out.

pr
- --
Pete Resnick             (...so what is a mojo, and why would one be rising?)
Graduate assistant - Philosophy Department, Gregory Hall, UIUC
System manager - Cognitive Science Group, Beckman Institute, UIUC
Internet: [e-mail]

+++++++++++++++++++++++++++

From: [e-mail] (Carl W. Haynes III)
Date: 24 Sep 92 02:41:04 GMT
Organization: Purdue University

In article <[e-mail]> [e-mail] (Pete Resnick) writes:
>[e-mail] (Al Hallstrom) writes:
>
>>I am writing a program that adds a new 'STR#' resource.  My problem is that
>>I don't quite understand the format.  I know the number of string is in
>>the first spot and then all the strings after that.
>
>As far as I know, you have to add them by hand (i.e. figure out what
>position to put them in, etc), but Munger is a nice routine to do this
>with. Check it out.

This is from the StringFunctions unit uploaded to AOL by Jon Wind:

 function SetIndString (theID, index: Integer; newStr: Str255): OSErr;
{ Set 'STR#' resource entry to a specific string }


 function SetIndString; {(theID, index: Integer; newStr: Str255): OSErr}
  var
   offset, place: LongInt;
   Hndl: Handle;
   TotalStrings: ^Integer;
   i, theError: Integer;
   EmptyCh: char;
 begin
  EmptyCh := char(0);
  { use Get1Resource to limit search to current resource fork }
  Hndl := GetResource('STR#', theID);
  if Hndl <> nil then
   begin
    HNoPurge(Hndl);
    TotalStrings := Pointer(ord4(hndl^));
    if index > TotalStrings^ then            { append string(s) }
     begin
      for i := Succ(TotalStrings^) to Pred(index) do
       place := PtrAndHand(Pointer(Ord4(@EmptyCh) + 1), Hndl, 1);
     { append string to STR# }
      place := PtrAndHand(Pointer(Ord4(@newStr)), Hndl, Succ(Length(newStr)));
      { set number of strings to reflect addition(s) }
      TotalStrings^ := index;
     end
    else            { replace existing string with new string }
     begin
      offset := 2;
      { get character offset of specified 'STR#' entry }
      for i := 1 to Pred(index) do
       offset := offset + Succ(Length(GetIndStr(theID, i)));
      place := Munger(Hndl,
                      offset,
                      nil,
                      Succ(Length(GetIndStr(theID, index))),
                      Pointer(Ord4(@newStr)),
                      Succ(Length(newStr)));
     end;
    ChangedResource(Hndl);
    theError := ResError;
    if theError = noErr then
     WriteResource(Hndl);
    HPurge(Hndl);
    ReleaseResource(Hndl);
   end
  else
   theError := resNotFound;
  SetIndString := theError;
 end; {of func SetIndString}



- --
Carl W. Haynes III
Software Arteeest                 ||  [e-mail] <-- temp. out of order
PO Box 2715                       ||  [e-mail]
W. Lafayette, IN 47906            ||  [e-mail]

---------------------------

From: [e-mail] (David Matiskella)
Subject: making Bit maps
Date: 24 Sep 92 04:45:47 GMT
Organization: University of Notre Dame


    What is the best way to generate bitmaps for a program?  Is there an easy
way to copy a picture from a paint program and store it as a bit map? Was a
resource structure for bitmaps ever defined? Any help will be much
appreciated.

+++++++++++++++++++++++++++

From: [e-mail]
Date: 24 Sep 92 14:45:22 -0300
Organization: Dalhousie University, Halifax, Nova Scotia, Canada

How do you make bitmaps? Well, basically, a bit map is a data structure that
contains the boundaries of the bitmap as well as a pointer to the bitmap
data.

Hence, you can declare a variable theBitMap:bitMap; in your variable
declaration section (assuming Pascal) to put it on the stack, or you might
want to put it in the heap if you're using lots of them.

You declare the baseAddr pointer by using NewPointer(sizeOfBitMap). Or, if
you're worried about heap fragmentation, you might declare it as a handle and
then lock it and singly dereference it when you want to use it with
Quickdraw routines.

Check out Steven Chernikoff's (sp?) book Mac Programming Secrets for formulas
for calculating the proper size of the bit map image.

The way I get bitmaps into my programs is to have multifinder on, and just
copy and paste images from Superpaint to ResEdit PICT resources. Don't use
the lasso tool as you get unpredictable boundaries. Then, I get the picture
resource using "GetPicture", set up the bitmap data structure based on the
bounds of the pict resource, ERASE the bitmap after using SetBits to switch
to it, and then draw the picture using DrawPicture. Now, you can dump the
picture by releasing the resource.

I don't think that there is any resedit data structure for bitmaps, but you
could easily make one using a TMPL resource. The only drawback is that you
can't see what the picture is unless you also write your own picker! I find
it more convenient to just keep them as picts in my resource file and convert
them to bitmaps in my program as I need them.

If you would like some code, I've got standard routines that I use called
MakeBitMap which does just what you think it might. However, I'm sure that
the code probably isn't the most efficient or avant garde. I've only been
programming for about a year and a half on the Mac (casually! I've got
a university degree to fiddle with too...) so others might have better
routines.

Hope this basic introduction to bitmaps helps.

Oh yeah, make sure that the visRgn isn't going to clip your drawing to the
bitmap, or else you will lose part of your image...


---------------------------

From: [e-mail] (Stephen W. Berkley)
Subject: Looking for LDEF
Date: 24 Sep 92 04:11:07 GMT
Organization: Dartmouth College, Hanover, NH

Believe it or not, some people actually *use* more than 32K worth of
list manager entries, so here's my beans....

I'm looking for an LDEF that acts like the standard LDEF (or with
improvements like independent column sizes...) that allows more than
32K worth of cell data.  More like 128K would be preferable.  If you
know where I could find this, please let me know, as it would be
painstakingly whittlesome to have to write one, when I know someone has
probably done it....

- -Steve Berkley
[e-mail]

+++++++++++++++++++++++++++

From: [e-mail] (Eric Bowman (bobo))
Date: 24 Sep 92 06:25:07 GMT
Organization: Reed College, Portland, OR

In article <[e-mail]> [e-mail] (Stephen W. Berkley) writes:
>I'm looking for an LDEF that acts like the standard LDEF (or with
>improvements like independent column sizes...) that allows more than
>32K worth of cell data.  More like 128K would be preferable.  If you
>know where I could find this, please let me know, as it would be
>painstakingly whittlesome to have to write one, when I know someone has
>probably done it....

Actually, writing an LDEF is pretty damn easy.  And for large amounts of
data, there are much better ways to store the data than how the LM does it
(kind of like a giant STR#, if I recall correctly). I would recommend
a q&d (quick & dirty) LDEF that knows how your program is storing the data,
 using the refCon of the ListRec to tell the LDEF where the data is.

This will in general be much faster than trying to use the standard LDEF
near the 32K limit, and will probably be faster and more memory efficient
since it's aware of your programs internal data structures & doesn't keep
it's own copy of what to display.

IM4 is pretty clear about how to write a LDEF; things *may* have changed
since IM6, I'm not sure (I doubt it).  Drop me a line if you have trouble.

later,
bobo
[e-mail]

+++++++++++++++++++++++++++

From: [e-mail] (Andrew E Page)
Date: 24 Sep 92 20:47:43 GMT
Organization: The World Public Access UNIX, Brookline, MA

In article <[e-mail]> [e-mail] (Stephen W. Berkley) writes:
>
>I'm looking for an LDEF that acts like the standard LDEF (or with
>improvements like independent column sizes...) that allows more than
>32K worth of cell data.  More like 128K would be preferable.  If you
>know where I could find this, please let me know, as it would be
>painstakingly whittlesome to have to write one, when I know someone has
>probably done it....

   And if some organization or person has done this complex and
difficult task, and worked it out into a nice compact easy to use
libary of objects or functions don't you believe that they'd like
to save it for their own products or at least earn some money for
liscensing it?



- --
Andrew E. Page   (Warrior Poet) |   Decision and Effort The Archer and Arrow
Mac Consultant                  |     The difference between what we are
Macintosh and DSP Technology    |           and what we want to be.

+++++++++++++++++++++++++++

From: [e-mail] (Keith Rollin)
Date: 25 Sep 92 00:31:10 GMT
Organization: Taligent

In article <[e-mail]>, [e-mail] (Eric Bowman
(bobo)) wrote:
>
> In article <[e-mail]> [e-mail] (Stephen W. Berkley) writes:
> >I'm looking for an LDEF that acts like the standard LDEF (or with
> >improvements like independent column sizes...) that allows more than
> >32K worth of cell data.  More like 128K would be preferable.  If you
> >know where I could find this, please let me know, as it would be
> >painstakingly whittlesome to have to write one, when I know someone has
> >probably done it....
>
> Actually, writing an LDEF is pretty damn easy.  And for large amounts of
> data, there are much better ways to store the data than how the LM does it
> (kind of like a giant STR#, if I recall correctly). I would recommend
> a q&d (quick & dirty) LDEF that knows how your program is storing the data,
>  using the refCon of the ListRec to tell the LDEF where the data is.
>
> This will in general be much faster than trying to use the standard LDEF
> near the 32K limit, and will probably be faster and more memory efficient
> since it's aware of your programs internal data structures & doesn't keep
> it's own copy of what to display.
>
> IM4 is pretty clear about how to write a LDEF; things *may* have changed
> since IM6, I'm not sure (I doubt it).  Drop me a line if you have trouble.

I don't think Stephen is going to be able to use an LDEF, no matter what
kind of data structure he uses. The scrollbar is not going to be able to
hold more than 32K discrete positive values. Additionally, if the List
Manager draws items by adjusting the port's origin, he won't be able to
draw a list if it is more than 32K pixels high.

Roll your own, Stephen, or look at the list/grid classes in MacApp and/or
TCL to see if they help.

- -----
Keith Rollin
Phantom Programmer
Taligent, Inc.

+++++++++++++++++++++++++++

From: [e-mail] (Stephen W. Berkley)
Date: 25 Sep 92 00:47:30 GMT
Organization: Dartmouth College, Hanover, NH

In article <[e-mail]>
[e-mail] (Andrew E Page) writes:

>    And if some organization or person has done this complex and
> difficult task, and worked it out into a nice compact easy to use
> libary of objects or functions don't you believe that they'd like
> to save it for their own products or at least earn some money for
> liscensing it?

What comradery!  Your advice is so helpful, I just can't wait to use
it!

- -Steve

+++++++++++++++++++++++++++

From: [e-mail] (Peter N Lewis)
Date: 25 Sep 92 02:13:30 GMT
Organization: NCRPDA, Curtin University

In article <[e-mail]>,
[e-mail] (Stephen W. Berkley) wrote:

> I'm looking for an LDEF that acts like the standard LDEF (or with
> improvements like independent column sizes...) that allows more than
> 32K worth of cell data.  More like 128K would be preferable.  If you
> know where I could find this, please let me know, as it would be
> painstakingly whittlesome to have to write one, when I know someone has
> probably done it....

LDEFs are trivial to write.  You can find a sample LDEF in Pascal in my
Talk code, available from sumex-aim.stanford.edu in /info-mac/source/pascal
(assuming they haven't expired it yet - you can find it at the umich
archive as well), and you can grab some sample LDEFs in C with TopSoft's
FilterTop source, which is available from syrinx.kgs.ukans.edu in the
/topsoft/filtertop directory (for more information about TopSoft or
FilterTop, mail [e-mail] or
[e-mail])

Have fun all,
   Peter.

_______________________________________________________________________
Peter N Lewis, NCRPDA, Curtin University       [e-mail]
GPO Box U1987, Perth WA 6001, AUSTRALIA             FAX: [phone]

+++++++++++++++++++++++++++

From: [e-mail] (Adam Winer)
Date: 25 Sep 92 03:52:54 GMT

[e-mail] (Keith Rollin) writes:

>In article <[e-mail]>, [e-mail] (Eric Bowman
>(bobo)) wrote:
>>
>> In article <[e-mail]> [e-mail] (Stephen W. Berkley) writes:
>> >I'm looking for an LDEF that acts like the standard LDEF (or with
>> >improvements like independent column sizes...) that allows more than
>> >32K worth of cell data.  More like 128K would be preferable.  If you
>> >know where I could find this, please let me know, as it would be
>> >painstakingly whittlesome to have to write one, when I know someone has
>> >probably done it....
>> since IM6, I'm not sure (I doubt it).  Drop me a line if you have trouble.

>I don't think Stephen is going to be able to use an LDEF, no matter what
>kind of data structure he uses. The scrollbar is not going to be able to
>hold more than 32K discrete positive values. Additionally, if the List
>Manager draws items by adjusting the port's origin, he won't be able to
>draw a list if it is more than 32K pixels high.

Well, you can definitely improve the amount of data the LDEF is storing.
If you're storing an average of, say 30 bytes of data per record,
you can only store about 1000 rows.

If you put a handle in refcon which points to the data stored by your
program, and with LSetCell pass offsets, you could store up to
about 8000 rows.  Now if there's a 32K pixel bound, you might only
be able to store about 2000 rows, but, hey, you've doubled its capacity.
And, actually, thinking about the way that LDEF's work, I strongly
doubt there is a 32K pixel bound, so you'll get 8000 rows.
You'll get really awful performance with the "easy" solution I can think
of, unless you can guarantee that each cell has data of a constant length,
or if you could put a decent upper bound on the size of a cell.

Adam
- --
Adam Winer        | The number you have reached is imaginary.
[e-mail]    | Please rotate your phone 90 degrees and
                        | try again.

+++++++++++++++++++++++++++

From: [e-mail] (Mimir Reynisson)
Date: 25 Sep 92 07:30:20 GMT

The list manager can't hold more than 32k of data because it uses
shorts as offsets into its data structres not because of the Control
Manager. And I dont think it uses SetOrigin() (maybe it does) because
it would have to have its own GrafPort, which it doesn't.

Anyway it's quite possible to squeeze more out of the list manager
by using the UserHandle field to acccess your own data. It's limited
to 32.000 elements in the list, but that's a lot more than 32Ks worth
of data.

Writing your own code to replace the list manager is very easy though.
And might work a lot better in the long run.

Hope this helps..

+++++++++++++++++++++++++++

From: [e-mail] (Bill Stackhouse)
Organization: StoneTablet Publishing
Date: Sat, 26 Sep 1992 01:02:36 GMT


There are 2 commerical libaries that are marketed as List Manager
replacements. Both have been on the market for since early summer
and have shipped products.

StoneTable from StoneTablet Publishing
   PO Box 12665
   Portland, OR 97212-0665
   internet: [e-mail]
   compuserve: 70303.2546

and

Matrix Engine from DataPak Software.
   9317 NE Highway 99, Suite G
   Vancouver, WA 98665-8900
   compuserve: 76424-3027



Portland, OR -- September 2, 1992 -- StoneTablet Publishing today
began shipping  StoneTable(TM) for use with MPW C. StoneTable is a
replacement for the Macintosh List Manager.  A version for use with
Think C has been available for several months.  Also with this release,
StoneTable will now support application defined cell validation
functions for both the Think C and MPW C versions.

StoneTable provides a rich set of functions for the Macintosh developer
who needs to display or accept data in a tabular form. Conversion from
the List Manager is straight forward because StoneTable contains
functions with similar names and parameters that are semantically
equivalent.

Functionality includes:
- - variable width columns
- - variable height rows
- - data in a cell can be edited in place
- - no internal limit to the amount of data that can be stored in a cell.
The amount of text displayed in a single cell is only limited by
TextEdit
- - multiple cells can be set at once
- - mouse down handling provides an optional interface for moving,
copying, selecting, and resizing a column or row plus scrolling and
editing the text in a cell
- - columns and rows can be hidden
- - optional lines between columns and/or rows can have a user supplied
pattern
- - irregular selections can be made
- - columns and rows can have default titles (letters, numbers, or blank)
- - ability to scroll individual cell text
- - columns can have applications supplied titles
- - the formatting (font, size, style, first line visible) of cells can
vary from cell to cell
- - columns and rows can have application supplied titles
- - ability to define a new drawing module for cell data
- - optional icon palette to aid in setting table mode for extended
selections, cell edits, etc. Useful for users that limited use of hands
and new users
- - define height of column title border and width of row title border
- - sort columns and rows
- - edit titles in place
- - cut/copy/paste cell/title text
- - have the cursor automatically change to the proper appearance as it
moves around the table
- - user written cell validation functions called during cell edits and
when cell text updated by application.

Questions may directed to:
     StoneTablet Publishing
     Internet: [e-mail]
     CompuServe: 70303,2546

- --
[e-mail]  Public Access User --- Not affiliated with TECHbooks
Public Access UNIX and Internet at [phone] (1200/2400, N81)

+++++++++++++++++++++++++++

From: [e-mail] (Bill Stackhouse)
Organization: StoneTablet Publishing
Date: Sun, 27 Sep 1992 05:01:49 GMT


In a prior msg, I have refered to 2 list manager replacements,
StoneTable and Matrix Engine.

I know that StoneTable is written to support
32K per cell and has a method for scrolling the text in a single
cell as well as scrolling the table (list). The functions that
directly replace the list manager have direct replacements in
StoneTable making conversion "simple" (eg. LNew becomes TMX_New).

I do not speak for
DataPak, therefore I do not know about the Matrix Engine. I believe
that it is supposed to support large text amounts for cells but
I don't know how they display it.

Bill Stackhouse
StoneTablet Publishing
[e-mail]

- --
[e-mail]  Public Access User --- Not affiliated with TECHbooks
Public Access UNIX and Internet at [phone] (1200/2400, N81)

+++++++++++++++++++++++++++

From: [e-mail] (Andrew Dent)
Date: 30 Sep 92 08:21:02 GMT
Organization: DIALix Services, Perth, Western Australia

DataPak also have a C library (inc source) called Bag of Tricks. It has
some simpler ListBox routines if you just want single column lists, with
hooks for extending to more complex lists.

Their list includes fixed width tabs, multiple selections and comes with
additional routines to make setting up dialogs VERY easy. They include a
complex example with multiple lists/dialog and font-size outlining.

I've just finished an external for FoxBase+/Mac which used the Bag of Tricks
lists and I found them VERY easy to use and easily adapted to an A4 world.

Andy Dent (A.D. Software - Mac & VAX programming)
94 Bermuda Dve, BALLAJURA  Western Australia  6066
Phone/Fax: [phone] (local)  [phone] (International)
       Internet: [e-mail]    Compuserve: 100033,3241

---------------------------

End of C.S.M.P. Digest
**********************